Investigations resolved membership and downstream integration failures by correcting membership expressions, aligning attribute sources, registering and scoping dynamic groups with downstream systems, and applying targeted workarounds for platform constraints and governance. Key outcomes and findings included:

After these corrections — updating rules for renamed UPNs/domains and guest formats, aligning attribute filters to canonical or alternate sources, registering groups with downstream systems, accounting for bulk‑add propagation, recording Okta/Workday attribute mappings, and applying governance controls — group memberships, Exchange permissions, People Picker/LMS resolution, Teams behaviour, and license assignment returned to expected behaviour.

Incidents were resolved by reconciling group state, membership, ownership, and cross‑system dependencies and by addressing third‑party provisioning/permission nuances so access and management workflows were reinstated. Actions taken included: - Restored deleted Teams/Microsoft 365 groups from the Azure AD/Teams Admin Center Deleted groups view and confirmed audit log entries; where members did not reappear immediately, membership was validated in Azure AD and missing members were re‑added. - Reassigned or elevated owners for ownerless or stale‑owner groups so group settings and membership could be managed; where SharePoint or Teams confidential channels had separate ownership requirements, administrators with the required scope were used after documented approver consent. - Removed departed users and delegated or elevated ownership for distribution lists and security groups to re‑enable self‑service membership and automated app integrations. - For hybrid topologies (on‑prem AD, Azure AD Connect/Sync, Okta), exported membership for records, removed or disabled groups in non‑authoritative sources, deleted groups in the authoritative system in the correct order, and validated that no orphaned references remained. - Reviewed and removed Access Package (Entitlement Management) bindings that referenced groups prior to deletion to avoid orphaned entitlement records. - Fixed automation failures that reported "entra user not found" or "add member failed" by restoring or reconciling deleted/stale user objects in Entra/Azure AD or by removing stale GUID references from Power Automate flows. - Restored external‑service access by mapping affected users to the correct AAD groups, ensuring groups were present in Azure AD, and allowing directory sync and license assignments to propagate. - Provisioned groups for third‑party SSO/provisioning consumers by creating Azure AD security groups, supplying ObjectID/GroupId to requesters, and ensuring the AAD group was assigned to the consuming Enterprise App so it became visible/provisioned in the third‑party system (for example AWS SSO). - Addressed AWS SSO/SSM specific failures by confirming group assignment into the AWS SSO Enterprise App and by verifying that the IAM permission set/role granted the required SSM actions (for example start/terminate session actions such as ssm:TerminateSession). Where users could sign into the AWS console but received SSM AccessDenied exceptions, permission‑set omissions or stale provisioning were updated and membership mappings were re‑provisioned so IAM permissions propagated. - Resolved application integration nuances where third‑party mail/marketing tools required a direct Entra/Azure AD (Microsoft Graph) connection to target Microsoft 365/AD groups rather than Exchange groups (for JungleMail this involved enabling an Azure AD Graph connection so "Microsoft 365, AD groups" could be selected). - Delivered ad‑hoc operational help: created requested security groups, established naming conventions, and provided hands‑on guidance (live sessions) for requesters who needed to create or manage Entra/AAD security groups. - When directory‑wide propagation, display issues, or audit‑log inconsistencies persisted, validated directory‑level membership and engaged Microsoft Support to investigate replication or service‑side problems. These actions restored group visibility, membership, owner management, third‑party provisioning, and automated flows across the affected systems.

The requested approvers were added as Approver entries to each impacted Access Package. The three additional users were inserted into the approver lists alongside the existing approvers, restoring adequate approval coverage for those AWS AIG2M access packages.

Tenant‑scoped pre‑provisioning of external guest principals and centralised guest‑management groups restored access and membership in multiple reports. A dedicated Power BI guest group (IUG-AAD-ASS-PowerBI-GuestAccounts) was used to pre‑provision affected B2B guests and removing them from the case list correlated with immediate restoration of Platform Analytics/LIBF report access and elimination of HTTP 401 AppMetadataInaccessible responses. Pre‑provisioning guests into application‑specific tenant allow‑lists or AAD groups restored SharePoint secure‑link access and corrected Power Platform/PowerApps group UI behaviour (including missing Add/Add2Group options until the external principal existed). Teams membership and shared‑channel invitation failures were resolved after guests were provisioned in the tenant, the target group's classification was changed to accept trusted guests, and B2B/shared‑channel settings were aligned. Attempts to establish true Shared Channel B2B Direct Connect failed when the partner did not provide the partner M365 Tenant ID and the partner group's Object‑ID (email addresses were insufficient); in those cases the only immediate fallback was adding users as guest accounts. Consumer/personal external identities (for example iCloud addresses or unmanaged personal Microsoft Accounts) were observed to be incompatible with some shared‑channel flows and often did not appear in the shared‑channel member selection UI; handling those cases required converting or provisioning the identity as a tenant guest or using standard channels. Where guest objects appeared as duplicate/mixed types or failed to provision because of mailbox/synchronization problems or incorrect invitation/approver metadata, repairing or recreating the guest object and fixing the invitation record restored group adds and application access. Cached/stale client sessions (including desktop Office/Teams clients and SSO intermediaries) produced intermittent AADSTS50020-like sign‑in mismatches; clearing client sessions or using an incognito window exposed cached identity mismatches and aligned observed behaviour with tenant‑side fixes. License‑related sign‑in failures for external Microsoft accounts were resolved by correcting license assignments and allowing propagation time (~15–20 minutes). Reactivating or renaming UPNs for disabled/renamed guest accounts and resending Teams invitations restored membership and allowed guests to rejoin groups. Finally, some tenants reported shared‑channel file storage anomalies (files appearing to land in a single container rather than per‑channel OneDrive folders); these symptoms correlated with missing tenant trust or unprovisioned guest objects in the partner relationship and were observed alongside the other shared‑channel failures.

Attribute and object discrepancies were resolved by identifying the authoritative source for each attribute or record and allowing existing provisioning or synchronizers to propagate corrected values, or by engaging the owners of those provisioning flows where mappings were missing. SharePoint UPA and telephone anomalies were diagnosed by exporting the SharePoint user profile JSON and identifying the authoritative source; on‑prem AD values were cleared when on‑prem was authoritative, and UPA entries were edited/removed in the SharePoint Admin Center when UPA was authoritative, which stopped the value surfacing in Teams and the GAL. Stale job titles, honorifics and work locations were corrected at the authoritative HR record (Workday) or cloud profile; HR→cloud/Okta provisioning propagation was observed in ~1–3 days. Workday attributes were standardized onto reserved extension attributes (for example JobProfile → extensionAttribute8, JobFamily → extensionAttribute9) and Okta mappings were verified; attributes were kept separate because Exchange extensionAttribute length limits (~250 chars) had previously caused concatenation loss. Mapping gaps (for example JobFamily and EmployeeType required by an LMS synchronizer) were resolved by raising change requests and engaging synchronizer owners to implement mappings so downstream imports consumed JobFamily and EmployeeType alongside EmployeeID. Profile photos that could not be removed via the M365 UI were removed using Microsoft Graph PowerShell (Remove-MgUserPhoto). Manager relationship mismatches were resolved by ensuring the manager attribute existed in the authoritative directory consumable by downstream services (Azure AD) or by provisioning manager accounts into on‑prem AD so on‑prem manager attributes referenced valid objects; provisioning mappings were verified to ensure manager relationships were written to the expected directory. Third‑party synchronizer failures (for example LMS365 or bespoke LMS connectors) were resolved by coordinating with synchronizer owners to configure field mappings and re‑run imports; previously non‑selectable attributes (for example CostCenter) were enabled or mapped after confirming they existed and were populated in Entra. Extension and custom attributes were updated at their authoritative source (on‑prem AD, Azure AD/Entra, or Exchange Online) or via an authorized application; app‑based updates were validated by confirming ClientID, TenantID and required Microsoft Graph permissions to modify user fullProperties and the app's authentication method. Missing or orphaned mailbox classification was addressed by running an existing Azure Automation runbook to populate CustomAttribute11 on Exchange Online non‑user mailboxes (shared, Bookings, room mailboxes) with a marker (for example "exoNonUserMailbox") enabling reliable filtering and grouping in Entra. Investigations of missing or duplicate accounts compared source systems (for example EPOS, CARE, MyCampus, Salesforce, PMS) with Azure AD and audit logs; where canonical identifiers had been stored in nonstandard fields (for example a changed surname placed in birthname) or where duplicate/incorrect AAD objects existed, canonical identifiers were reconciled and formal provisioning change requests were raised to restore or reprovision the affected Azure AD objects so downstream consumers could consume consistent attributes. Reporting and dashboard omissions (for example deputy schedules not appearing in Power BI) were resolved by confirming the PMS→AAD mapping and the target Azure AD object identity (UPN/objectId/immutableId), removing or consolidating duplicate/incorrect AAD identities, and ensuring Power BI licensing and workspace access were assigned to the resolved user object so scheduled activities reconciled and appeared in dashboards.

Incidents were resolved according to the identified root cause and context. Local desktop sign‑in failures (unexpected Office sign‑outs, sign‑in loops, or apps obtaining no tokens while browser sign‑in succeeded) were restored by re‑authenticating accounts and clearing local token stores and browser cookies so fresh tokens were issued; where symptoms indicated AAD broker/token‑broker corruption, device‑level remediation or use of an alternate device was required and some macOS enrollments that reported “Microsoft Entra ID missing” were resolved only after reimaging affected iMacs. OAuth failures from expired client secrets (AADSTS7000222) were resolved by creating new client secrets and delivering new secret values to downstream services; failures caused by submitting secret identifiers (IDs) instead of secret values (AADSTS7000215) were restored after replacing the submitted value with the actual secret. When longer‑lived or more secure credentials were appropriate, certificate credentials were adopted to replace frequent client‑secret rotation. Redirect‑URI mismatch errors (AADSTS50011) stopped after the request redirect URI matched the app registration configuration, and endpoint method errors (AADSTS900561) were traced to clients using the wrong HTTP method or flow. Microsoft Graph 403/authorization_requestdenied outcomes were resolved by correcting permission types and role assignments, granting the required delegated or application Graph permissions and applying admin consent so API calls succeeded; a Power BI Sentinel outage was resolved after a service principal’s conflicting application vs delegated permissions were corrected. Azure AD B2C failures that produced blank screens or unexpected downloads were traced to reuse of single‑use libfb2c.b2clogin.com redirect URLs or obsolete login links; initiating a fresh canonical B2C login flow removed the symptom. Sign‑in failures that reported incorrect username/password, invalid tenant identifiers, or “user not found” errors were traced to mistyped addresses, malformed tenant identifiers (for example duplicated GUIDs producing AADSTS900023), incorrect tenant/account selection, disabled or deprovisioned accounts, or misaligned group membership/licensing; restoration of the correct enabled user identity or routing to local tenant administrators resolved those cases. Windows Hello PIN reset failures on Windows 10 were traced to inability to register the tenant PIN‑reset app and were escalated to Microsoft Support while Windows 11 devices used alternate flows. Newer tickets showed two additional, specific patterns: support resent fresh Microsoft emailed sign‑in (magic) links when users received expired or non‑working authentication links, and an integration (UiPath) failed because its Azure AD app registration remained single‑tenant while the authentication flow used the common tenant; the single‑tenant cause was recorded although that ticket did not include a documented remediation. Overall, incidents were closed after restoring valid credentials/redirects/permission consent or when device/service‑side token caches and app registrations were corrected so tokens could be acquired and APIs authenticated successfully.

Missing or incomplete site/team entries were resolved by creating the required Entra (Azure AD) groups and ensuring they matched existing Standortteam conventions. A static Entra group was created for the Duisburg site and two dynamic Standortteam groups were created for Dortmund and Magdeburg using m365AccountToolbox with the same membership rule used by other Standortteam groups so users with matching officeLocation values were included. Exchange Online 'AcceptMessagesFrom' settings on the new Standortteam groups were set to include the internal IUG sender used by existing groups. Group properties, links and object IDs were recorded. Each group was confirmed present in the directory and available to the StandortList reporting and monitoring systems.

Access problems were resolved by addressing several distinct root causes found across tickets:

Each of the above actions corresponded to ticket evidence: MFA completion restored PIM activation flows; reauthorizing PWA/service accounts removed 401 JSON errors; correcting PIM links exposed missing UI elements; recreating a misaligned PWA account restored role activation; and adding users to existing PIM-assigned groups or creating permanent-role groups provided the required Edit/admin permissions.

Conflicts were resolved by consolidating the intended addresses onto a single authoritative Entra/Azure AD account and removing or reconciling duplicate/stale identities. userPrincipalName, mail and proxyAddresses were updated through Microsoft Graph and the primary SMTP was set using the uppercase SMTP: convention so Exchange recognized the primary address while preserving existing non-target aliases. When license assignment (group or manual) failed because the target address existed as a proxyAddresses entry on another account, the conflicting alias was removed from the other account and licenses were then assigned successfully. In cases caused by a typo or an external/stale account imported from an identity provider, the external/duplicate record was deleted and the remaining account’s UPN/mail were aligned to the corrected address; Okta profile fixes were applied where the source of the duplicate originated there. Final Microsoft Graph output and Exchange/Outlook propagation were inspected to confirm proxyAddresses, userPrincipalName and mail reflected the intended state and that dependent services acknowledged the change.

Applications were migrated to the new App Proxy server (vmiuitapwe1p1) and the legacy connector server (CPGAZU1ADSS1) was shut down so the connector could reach the platform's inactivity threshold. The legacy connector was allowed to be removed by the built-in 10-day auto-delete process and legacy application entries in the connector group were cleaned up. It was noted that restarting the old connector reset the 10-day timer and delayed automatic deletion.

Both issues were transient, service-side/backend failures in the Entra portal. The dynamic content failures were resolved after Microsoft restored the portal's dynamic module endpoints and the HTTP 408 timeouts ceased; once the endpoints recovered, dynamic blades (for example UserDetailsResetPasswordBlade, UsersArea, ReportsArea, Fx/Composition/DataContext) loaded normally and actions such as MFA resets succeeded. The favorites persistence issue resolved itself after a server-side/backend fix (favorites began persisting again on 2023-05-22); no client-side remediation steps were recorded. In all cases normal portal functionality returned after Microsoft’s service-side recovery.

Support obtained and entered the BitLocker recovery key and then authenticated on the device using the Windows "Other user" sign-in option so the user signed in with the correct Azure AD account context after the account change or firmware event. After the recovery key was entered and the user signed in via Other user, the device decrypted and the user regained access to Outlook and Teams. In a related incident on a Lenovo device, recurring BIOS/firmware update prompts and a previously accepted BIOS update had preceded the BitLocker recovery and Microsoft sign-in failures; the same recovery-key entry and correct-account sign-in restored the device.

The incidents were resolved by collecting an authoritative mapping of each Team's GroupId to the desired classification from the requestor, validating those classification values against IT/compliance policy, and programmatically applying the changes to both Teams and Microsoft 365/Azure AD group objects. Changes were executed in bulk via PowerShell and Entra/Azure AD cmdlets — Set-Team -GroupId -Classification was used and corresponding Microsoft 365 group mailbox classification attributes were synchronized where separate 'old' and 'new' fields existed. After the scripted updates, classification attributes in Teams, Microsoft 365 Groups, and Azure AD reflected the requested values. Automation for Jira was used in some cases to coordinate requests and track the reclassification work.

Work consisted of requirements capture and stakeholder coordination rather than an immediate deployment. The requested student mail domain format was recorded (initially firstname.surname@hu-study.org, later changed to firstname.surname@iu-healthuni.org) and Office access requirements were documented. Provisioning was deferred: the team identified the Course Feed implementation and IUCP go-live as hard dependencies, and flagged tenant interaction/use-case, group-creation policy, and patient-data protection constraints for decisions by the owning governance groups. No tenant was provisioned within this ticket; progress was paused pending those stakeholder decisions and dependent projects.

Support determined the 'renew/expiring' prompt was a UI surface of the tenant group expiration/inactivity policy that flagged groups with no recent activity; in multiple incidents the policy lifecycle executed deletions and audit records showed the automated actor 'Microsoft Approval Management' performing the 'Delete group' actions. For the originally reported dynamic group, support confirmed there was no required configuration change and the group would remain while actively used. In the Course Feed incidents, affected Teams groups were restored by the external provider where restores occurred inside Azure AD's soft-delete retention window; when deletions were discovered after the retention period restoration was not possible. Some restore and membership-update attempts produced Microsoft.Online.DirectoryServices.DirectoryValueExistsException errors caused by conflicting directory objects during restoration or synchronization. The issues were resolved by scoping the tenant expiration policy to exclude groups that must be retained and by implementing programmatic renewal/exemption flows (Microsoft Graph or Power Automate) for groups that needed automatic renewal; applying exclusions/automation and restoring groups within the retention window stopped the recurring deletions.

Support confirmed the Azure login for the non-production subscription was the requested onmicrosoft account, validated the username matched the onmicrosoft address, and applied/confirmed the required Azure DevOps permissions so both Azure portal access and DevOps access aligned to the onmicrosoft account.

The issue was caused by an Azure AD administrator policy that prevented the specific user account from registering or joining devices. Incidents were resolved by removing the policy restriction or placing the user into an Azure AD group that was permitted to register/join devices (the tenant’s "W11" group in the reported case). After the group membership change the user retried sign-in and the device completed Azure AD join. In one case Intune/Company Portal did not appear after sign-in; that device was escalated to specialists and reimaged to restore management and app deployment. A temporary workaround used while the device was being remediated was to install Office apps directly from the Microsoft website.

Provisioning and credential or role fixes were performed depending on the case. A dedicated Entra/Azure AD service account was created for the requesting team and initial credentials were provided; when the recorded password failed (likely a digit transposition), support reset the password and verified successful sign‑in and access to Microsoft Forms and Power Automate. An Entra ID service account was created for Catalyst Center to enable TACACS+ authentication via Portnox and the credentials were handed off to the requester. The 'Password Administrator' role was assigned in Entra/Azure AD to the CSS_ManagedIdentityForPlaybooks managed identity (replacing the previous assignment on the decommissioned InfoSec_ManagedIdentity), which restored Logic Apps/incident‑response playbook execution. In each incident, creating the correct account or managed identity, ensuring the appropriate Entra/Azure AD role assignment, and correcting/handing off credentials resolved the automation or authentication failures.

IT confirmed that Microsoft Entra External ID (CIAM) was the appropriate approach for this scenario because the Syntea Learn+ app required open social sign‑in and email self‑signup rather than invitation-only guest access. The External ID configuration was implemented for the app: Google was added as an external identity provider (using the app's Google OAuth client ID/secret), email-based sign-up was enabled (email OTP/local account option), and the app registration's authentication settings and redirect URIs were updated to accept External ID authentication flows. A policy review documented alignment with IU Azure Cloud requirements. Azure AD B2B Collaboration was not used because it is invitation-centric and did not meet the self-service social/email sign-up requirement.

The new Entra ID Connect instance was validated in a test environment and then cut over to production. After the successful switch, the previous Connect server (cpgazu1aad1) was placed into staging-mode to provide a rollback/fallback option and to monitor sync behavior. The old server was scheduled for removal following a monitoring period once normal synchronization was confirmed.